Database systems store large amounts of user data in a single location in an organized structure to allow rapid access. In particular, databases store user data from several users in a single system, which is accessed by all users. The number of users accessing a database may include tens, hundreds, or thousands of users. Thus, some database systems are continuously reading and writing user data.
Backups of the database system are critical to ensuring the safety of the user data stored thereon. Performing a backup may require a pause in availability of the database system to allow a snapshot to be created and copied to another storage device. Although the user data copied to the backup is identical to the user data stored in the database system, control data associated with the database system may be altered or dropped during creation of the backup. Further, additional control data may be written to the backup not contained in the database system.
Thus, each backup created from the database system uses different control data, which must be independently created during a backup process. Multiple backups may be created from the database system to decrease the likelihood of loss of user data or to create an alternate copy of the database for testing, evaluation, or remote backup. However, because the database system may be temporarily unavailable during the creation of a backup, creating multiple backups may prolong the unavailability of the database system. FIG. 1 is a flow chart illustrating a conventional method for creating multiple backups from a database. A method 100 begins at block 102 with copying a database to a first backup file. The method 100 continues to block 104 with copying a database or an audit log to a second backup file. During copying at block 102 and block 104 the database system may be unavailable. In the case of an audit backup, the original data may no longer be available or a delay in deleting archived logs could cause database or system availability issues.
In conventional systems, a basic replicate move feature may have no way to continue replication for a set if something happened with the original move history or move tapes. An integrated recovery utility (IRU) may enforce retention of a contiguous audit trail in each set by controlling a start point. If a problem is encountered in the original move set, the IRU may require deletion of any alternate move sets and starting over to continue creating replicated move tapes. However, sites might want to retain the existing information in a move set while starting over after an issue.
In addition, a configuration parameter TAPE-TYPE-OVERRIDE may be used to replace the tape type specified in syntax or found in a history file or tape trailer with another compatible type. The original type may be retained for history file entries, tape trailers, and messages. This may allow users to replace obsolete drives with compatible drives having different identifiers. It may also enable absolute device or control unit assignment (something that is not supported in TYPE clause syntax).
Some sites may reserve drives for IRU backups and may need to access those drives using absolute or control unit assignment. Since the syntax does not support specifying absolute device names in the TYPE clause, TAPE-TYPE-OVERRIDE is a recommended mechanism to direct IRU tape processing to these devices.
An existing form of TAPE-TYPE-OVERRIDE may work well for most commands (which use a single tape at a time). However, it may not work well for commands that use multiple reels at the same time: B-option DUMP, DUMP CHANGES, or MOVE commands and REPLICATE commands.
An improvement is needed in the use of TAPE-TYPE-OVERRIDE in the REPLICATE command. This parameter may currently be applied to both the source and destination, which may not be the desired effect. It may not work at all for absolute devices (both tapes cannot be using the same drive), and might not work for control unit or general cases if the replication is to occur to a different drive type than the original backup.